UNITED STATES DEPARTMENT OF COMMERCE 
iiUni-ted S-ta-tes Pa-ten-t and Trademaz-k OfFice 



August 26, 2004 



THIS IS TO CERTIFY THAT ANNEXED HERETO IS A TRUE COPY FROM 
THE RECORDS OF THE UNITED STATES PATENT AND TRADEMARK 
OFFICE OF THOSE PAPERS OF THE BELOW IDENTIFIED PATENT 
APPLICATION THAT MET THE REQUIREMENTS TO BE GRANTED A 
FILING DATE. 



P 



APPLICATION NUMBER: 60/500,499 
FILING DATE: September 05, 2003 

RELATED PCT APPLICATION NUMBER: PCT/VS04/253981 



Certified by 




|:;x;x|;;:;:;:t;:;:;:;:;:;:;:;:;: 











Jon W Dudas 

^Acting Under Secretary of Commerce 
;:for Intellectual Property 
sand Acting Director of the U.S- 
iiPatent and Trademark Office 



r 



PIsasa type a phis ^ (♦) insid» tHs boc-^ Q 



PTOfSBne(2-98) ■ 
Appfwed tef use throuBh OI/gVaOQI. Ojiffl 0651 jD0O7 



Patent and TiBttefliafkOmoo; aS. DEPARTMBrT OF COMMERCE 
UntterihePapemorfcfteduciJonActof i995.noper50(ttar9reqia«dtorespiXKttoacoU8clhmolhtorim 
vald 0MB oontro) number. 

PROVISIONAL APPLICATION FOR PATENT COVER SHEET «; 

This {s a request for filing a PROVISIONAL APPUCATION FOR PATENT under 37 CFR 1 ^3 <c). 



Given Name (first end nWs (3 any]) 



Haihong 
Marc 



tNVENTOR(S) 



FamSy Kama ot Surname 



Zheng 
Greis 



Residence 
(Cily and etther State or Foreign Country) 



136 Bridviell Ui. Coppell. TX 7S019 
7919 N. Glen Dr.. Irving. TX 75063 



[~] Additional mventois are being named on the separately numbered sheets attached hereto 



TITLE OF TME INVENTION f280 characters max) 



CONTEXT-BASED ADAPTIVE BINARY ARITHMETIC CODING (CABAC) 



Direct all correspondence ra 
P*| Customer Number 

OR 



CORRESPONDENCE ADDRESS 
► 



Type Customer Number here 



Place Cvstomer Number 
Bar Code Label here 



□ 



Firm Of 

(ndhndua) Name 



Address 



Address 



City 



Country 



Nokia Corporation, (Brian Rivers) 



Milan Patel, Patent Department 



6000 Connection Or. 



Irving 



USA 



State 



TX 



Telephone 858-831 -5975 Fax 858-831-6519 



ZIP 



75039 



ENCLOSED APPUCATION PARTS (check aU that apply) 



Specitication Number of Pages 
{✓| Dfawing(s) Number of Sheets 



j I Small Entity Statement 
[✓] Other (specify) 



Return Posteafd I 



METHOD OF PAYMENT OF FILING FEES FOR THIS PROVISIONAL APPUCATION FOR PATENT (check one) 



\ I A Check or money order ie enclosed to cover the filing fees 

□ The Commissioner is hereby authorized to charge filing ■ ■ 
fees or credit any overpayment to Deposit Account Number} 50-0270 | 



FlUNG FEE 
AMOUNT ($) 



$160.00 



The invention was made by an agency of the United States Government or under a contract with an agency of the 
United Stales Government 
0 No. 

Q Yes, the name d tiie U.S. Government agency and the Government oontraci number are: 



Respecthjiiy submitted, 
SIGNATURE 



ntted. y 7/ 
^ Milan Patel 



Date 



TYPED or PRINTED NAME" 



TELEPHONE" 



e5frg31-5ff7» 



REGISTRATION NO, 
(if appropriate) 
Docket Number 



42.242 



NC37291 



J 



USE ONLY FOR FILING A PROVISIONAL APPLICATION FOR PATENT 

This oodection of information is reouired by 37 CFR 1.51. The information is used by the public to fBe (and by the PTO to 

gmcess) a provi^na) appTtcation. ConfidentiaSty is governed by 35 U.S.C. 122 and 37 CFR 1 .14. This collection is estimated 
> take 8 hours to cornplete. tnchiding gathering, preparing, and submitting the complete provisional application to the PTO. 
Time wll vary dependrng upon the ind'rvMual case. Any comments on the amouni of lime you require to complete this form 
andtor suggestions lor reducing this bunlen. should be sent to the Chief Information Ofwer. U.S. Patent and Trademark 
Offtee. U.S. Department of Commerce. Washington, D.C.. 20231. DO NOT SEND FEES OR COMPLETED FORMS TO THIS 
ADDRESS. SEND TO: Box Provisional Appltca&n. Assistant Commisskmer for Patents. Washington. D.C.. 20231. 



PROVISIONAL APPLICATION COVER SHEET , 

Additional Page ■ 

PTQ/SB/18 (2-9^ 

Approved for use through 01/31/2001. 0MB 0651-0037 
Patoit and Tratlema* Otftce; U.a DEPARTMENT OF COMMERCE 
Under the Papemtk Reduction Ad of 1995. no pefsons are required to respond to a collection o) tnlormation unless U disptaysa 
valid 0MB control number. 



Docket Number 



NC37291 



Type a ptus sign {+) 



INVENTOR(SyAPPUCANT(S) 



Given Name (first and middle fit anvn 



FamBy Of Surname 



(dtvand either Stale or Foreion Coumrvl 



Number ^ of ^ 



+ 



CERTIFICATION 



I hereby certify that this correspondence as Identified is being deposited with th United 
States Postal Service as Express Mail Number ^^BT^S^^^*^^ U-S pn 
i 7Cx& . in an envelope addressed to: 



MS - Provisional Application 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 





ft 




1 


Signature 


ofde 


|son mailing document 



Name 




Date 



Express Mail No.EU334545022US 

Provisional Application for Haihong Zheng et a1. 

NC37291 

QoS SUPPORT IN CDMA2000 R-P NETWORK 



BACKGROUND OF THE INVENTION 

Without limiting the scope of the invention, its background is described in connection 
with network architectures that prioritize data according to type. 

The differentiated sen^ices (DiffServ) architecture described in RFC2475 is based on a 
simple model where traffic entering a network is classified and possibly conditioned (e.g., 
martced, metered, policed, shaped) at the boundaries of the networic (i.e., at the edge router), 
and assigned to different behavior aggregates. Each behavior aggregate is identified by a 
single Differentiated Services Code Point (DSCP). Within the core of the networtc, packets are 
fOHA/arded according to the per-hop behavior associated with the DSCP. Therefore, with the 
DiffSen/ architecture, the complexity is pushed into the edge of the network, while keeping the 
core routers simple. 

The edge routers in a DiffServ domain are also tenned as ingress node or egress node, 
depending on the traffic direction. In a typical CDIVIA2000/3GPP2 networic as shown in Figure 1 , 
the Radio Node (RN), e.g. BTS is the ingress node for the uplink traffic, while the Packet Data 
Switching Node (PDSN) is the ingress node for the downlink traffic. In order to provide the 
DiffServ based QoS inskle the R-P network (i.e., the IP networic connecting RN and PDSN), the 
DiffSen/ functionality for the edge router, such as packet classification, martung, metering, 
policing and shaping should be implemented in RN and PDSN. In order to perfonm these 
functions, all the Oaulity of Sen/ice (QoS) related infonnation needs to t>e properly 
relayed/configured into RN and PDSN. However, as described in section 2, the current 3GPP2 
specifteation doesn't fully support such functionality. 

In the current 3QPP2 standardization [3QPP2 P.S0001 C.4], flow mapping and 
treatment is originally introduced to map a particular downlink flow to a service instance. As 
described in 3GPP2 specificatton [3GPP2 P. S0001], in addition to a main service instance, a 
MN may open one or more auxiliary service instances to carry traffic that is not suitable for the 
main service instance. In order to effectively use the auxiliary sen/ice instance, the PDSN needs 
to be infomned about the packet filters (i.e., the infonmation used by the PDSN to classify which 
packet to be sent on which service instance). 

The mechanism to support DiffSen/ QoS in R-P networtc and external network has not 
been clearty defined in the current 3GPP2 standardization. The flow mapping mechanism 
described above can only be used to map a downlink traffic flow to a particular auxiliary service 
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instance, however, the mechanism for POSN to obtain the CtoS requirement of the flows inside 
an auxiliary service instance hasn't been defined. Although [TR45: Interoperability Specification 
(lOS) for cdma200 Access Network interfaces - Part 2 Transporf , PN-4545.2*RV3, Ballot 
Version October 2002] also stated that RAN policies or local policies defined by service provider 
can be used by RN and PDSN to mark and condition the uplink and downlink traffic, the 
mechanism for RN and PDSN to obtain the QoS requirement of ttie flows in order to apply the 
policy are not defined at all. 

As may be seen, an improved mechanism to improve functionality between two network 
nodes could provide an improved network architecture. 

FIELD OF THE INVENTION 

The present invention relates, in general, to prioritization of data between network nodes; and, 
in particular, to a method and system for establishing prioritization requirements between 
network nodes. 

BRIEF SUMMARY OF THE INVENTION 

The present invention presents an improved method and system for enabling traffic flow 
management between two nodes. 

This invention report proposes several approaches to provide DiffSen/ support to both 
uplink and downlink traffic over the R-P network and external network. In order for RN and 
PDSN to provide QoS and/or enforce QoS polices, they need to obtain the QoS requirement 
from the mobile node. This invention report to signal such QoS requirement at the link level 
using QoS.BLOB information or at the IP level via an extended dynamic ftow mapping 
mechanism. This invention report also proposes how to use these QoS informatton at RN and 
PDSN to provide QoS support to the R-P network and external network. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the present Invention, including its features and 
advantages, reference is made to the detailed descriptton of the invention, taken in conjunction 
with the accompanying drawings of which: 

FIG. 1 DitfSen^ Domains in 3GPP2 Network System; 

FIG. 2 Flow Mapping and DiffSen/ Conditioning for Downlink Traffic: Solution 1 ; 

FIG. 3 Flow Mapping and DiffSen^ Conditioning for Downlink Traffic: Solution 2; 
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FIG. 4 Flow Mapping and DiffServ Conditioning for Uplink Traffic: Solution 1; 

FIG. 5 Row Mapping and DiffSen/ Conditioning for Uplink Traffic: Solution 2; 

FIG. 6 Flow Mapping and DiffServ Conditioning for Uplink Traffic: Solution 3; and 

FIG. 7 Integration of SolutionZ/uplink and Solution 2/downlink 

DETAILED DESCRIPTION OF THE INVENTION 

While the use and implemer^tation of particular embodiments of the present invention are 
presented in detail below, it will be understood that the present invention provides many 
inventive concepts which can be embodied in a wide variety of contexts. The specific 
embodiments discussed herein are mere illustrations of specific ways for making and using the 
invention and are not intended to limit the scope of the invention. 

Appendix: Hereby incorporated by reference is an attached contribution by Nokia to a 3"* 
Generation Project 2 "3GPP2" standards body titled "Nokia Procedures for Supporting End-to- 
End QoS in the 3GPP2 System". 

A modified RSVP RESV message is used by the MS to signal one or more packet filters, 
called Traffic Flow Templates (TFT). The TFT s are only used to map downlink traffic to auxiliary 
service instance. The TFT IE, RESV message and protocol operation of dynamic flow mapping 
in downlink direction are described in [3GPP2 P. S0001] and will not be repeated in this 
document. The mechanism defined for flow mapping can be easily extended to provide QoS 
support to both uplink and downlink traffic over R-P bearer and external network. The QoS 
support defined here is DiffServ support and requires R-P network and external network to be 
DiffServ capable. Some approaches proposed in this invention report extend the service 
mapping mechanism to support DiffServ QoS in R-P and external networks. 

The QoS^BLOB defined in (TIA/IS-707-A-3] is used by the MN to signal the RN its QoS 
requirement for both uplink and downlink traffic. (Although QoS^BLOB is currently only defined 
in service option 33, it can be used for otiier type of sen/ice option as well.) Based on tiie 
QoS.BL-OB, RN provides conrespondent QoS over the air interface. However, no QoS support 
is defined for downlink traffic over the R*P connection. Although the downlink traffic coming into 
the PDSN from the external network could be marked witti DSCP, PDSN may need to remark 
the packet based on downlink QoS requirement from the MN, user subscription policy (e.g., 
bandwidtfi limitation for a particular session) and ottier local network policy. In order for PDSN 
to mark ttie downlink traffic correcUy based on its QoS requirements, besides the TFT of the 
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flow, the QoS requirements of the flow need to be signaled to the PDSN as well. Two solutions 
are listed below. 

Solution 1: RN sends downlink QoS information to PDSN - The basic idea of this 
approach is that RN obtains or derives the QoS requirement from the QoS.BLOB and then 
sends the QoS requirement to PDSN. This requires modification to the A1 1 interface to carry 
the QoS requirement of the downlink traffic. 

As shown in 

Figure 2, if MOB^QoS is set. the MN sends OM/EOM message with QoS_BLOB to the 
RN; otherwise, RN initiates the service negotiation or sen^ice option negotiation procedure, 
which carries the QoS.BLOB. Regardless of the procedure used, after obtaining the 
QoS.BLOB, RN sends the QoS Information to the PDSN in an A1 1 message. Such A1 1 
nnessage could be a modified All RRQ message. (The modification to the existing interface 
and procedures in different network entities are shown in bold). The QoS information could be 
in the fonmat of QoS.BLOB or RSVP FLOWSPEC or other QoS parameters. The PDSN 
obtains the downlink QoS requirement from the QoS Informalion earned in A1 1 message and 
then decides what DiffServ policies to be applied, based on local network policy and the user 
subscription profile. The DiffServ policies could include, but are not limited to, DSCP marking 
and traffic policing/shaping poltoies. The definition of these policies is subject to different service 
providers and is not within the scope of this document Only two examples of the DiffServ 
policies are given betow. 

Examplel - DtffSen^ marking policy: The downlink traffic with QoS infonfnation with a 
requirement of requested bandwidth x bps, requested maximum delay y ms, and acceptable 
toss rate z%, will be marked with DSCP d1 . 

Example2 - traffic policing/shaping policy: The streaming application (specified by Traffic_Class 
or Application ID) used by a Gold user (high priority) should not exceed X bps during busy hour. 
Such policy could be specified in user QoS profile or defined by local network. Although the RN 
is aware of those policies, instead of possibly overloading R-P network, the PDSN can enforce 
the policies already to downlink traffic by dropping or shaping the out-of-profile traffic based on 
such a policy. 

After the DiffSen/ polices (e.g., DSCP used for the flows mapped to the sen/ice instance 
identified by the SRJD) are decided based on the QoS infomnation for the sen/ice instance, 
they are mapped with the con'espondent SRJD. The PDSN then responds to the RN with A1 1 
message, such as A1 1 RRP message. In addition, in order for PDSN to map the downlink 
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traffic into the correct service instance, the MN signals the TFT for the downlink traffic to the 
PDSN as defined in cunrent CDMA2000 specification. When downlink traffic passes the PDSN, 
the PDSN first maps the packets into the conrect service instance based on the TFT, and then 
marks the packet with the correct DSCP associated with the SRJD. Other possible DiffServ 
functions (e.g., policing, shaping) can be performed as well. 

Solution 2: MS sends downlink QoS requirement to PDSN 

The basic idea, as shown in 
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Figure 3, is to signal the QoS requirements of the dovymiink traffic along with the TFT in the 
RESV message from the MN to the PDSN. The QoS requirement carried in the RESV message 
could still be the QoS.BLOB or a new information element or the FLOWSPEC defined for 
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Standard RSVP. After receiving the RESV message, the PDSN decides the DiffServ policy to 
be applied, based on the QoS requirement for the downlink traffic and creates the mapping 
between TFT, SRJD and DiffSen^ policy {as described for solution 1). 

The traffic handling procedure is the same as the ones defined in solution 1 . 

5.2 Uplink Traffic 

In the current CDMA2000 specification, uplink QoS requirement can be carried in the 
QoS.BLOB and signaled between MN and RN. However, it is not specified how QoS is 
provided for the uplink traffic passing through the RN toward the PDSN and then to the external 
networks. In order to provide QoS support beyond the RN, the RN needs to be informed of the 
QoS requirements of the uplink traffic and it has to apply the correspondent DiffServ traffic 
handling policies. Three solutions are described below. 

Solutioni : Mapping from QoS.BLOB to DSCP - The baste idea of this approach is to 
directly map QoS.BLOB into DiffServ DSCP and other diffsev polteies. As shown in Figure 4, 
after obtaining QoS.BLOB for the sen/ice instance, based on the QoS requirement carried in 
the QoS_BLOB, the RN decides which DiffServ policies (DSCP maricing) are to be applied to 
the service instance, then establishes the mapping between SRJD and DiffServ policy (e.g., 
DSCP). 

Solution 2: Mapping instructed by PDSN - The basic Idea is to cany the QoS requirement for 
the uplink traffic in the RESV message, whteh is used to signal flow mapping in the current 
CDMA2000 specification. As shown in Figure 5, after receiving the uplink QoS requirement in 
the RESV message from MN, the PDSN decides v\rhich DiffServ policy (e.g., DSCP) is used for 
uplink traffic based on the QoS requirement. The QoS requirements sent in the RESV message 
could be in the QoS„BLOB format, or in the RSVP FLOWSPEC fomiat, or a new information 
element standardized in 3GPP2 or other fomm. After creating the mapping between SRJD and 
DiffServ policy, the PDSN not only configures it locally but also pushes the uplink traffic handling 
policy into the RN. The protocol used by PDSN to push the DiffServ polfcy for the uplink traffic 
could be COPS or modified A1 1 messages. Only COPS messages are illustrated in Figure 5. 

Solution 3: Mapping at RN via interceptten of RESV message - As shown in Figure 6, this 
approach is similar to Solution 2, where uplink QoS requirements are carried in the RESV 
messages. However, when the RESV message reaches the RN, the RN Intercepts the 
message and extracts the SR_ID and uplink QoS requirements, and then decides on the 
DiffServ policy and configures the policy locally. If the RESV message only carries the uplink 
QoS requirement, which is not needed for PDSN, RN can tenninate the RESV message and 
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sends the RESV.CONF message back to MN. Otherwise, RN forwards the RESV message 
toward the PDSN. The PDSN ignores the uplink QoS requirement information carried in the 
RESV message, and only processes the downlink part if exists. 

5.3 Integrated Solution for Uplink and Downlink Traffic 

Although the solutions for uplink traffic and downlink traffk: are documented separately, 
the correspondent solutions can be merged together. For example, when solutk>n2 for downlink 
traffic and solution 2 for uplink traffic are merged, the integrated solution is illustrated in Figure 
7. Other combinations are also possible and are not illustrated in this document. 

While this invention has been described with reference to particular embodiments, this 
description is not intended to be limiting. Various modifications and combinations of the 
illustrative embodiments, as well as other embodiments of the invention, will be apparent to 
persons skilled in the art. It is, therefore, intended that the appended claims encompass any 
such modifications or embodiments. 
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ABSTRACT OF THE DISCLOSURE 

This invention report proposes several approaches to provide DiffServ support to both 
uplink and downlink traffic over the R-P network and external network. In order for RN and 
PDSN to provide QoS and/or enforce QoS policies, they need to obtain the QoS requirement 
fronn the mobile node. This invention report to signal such QoS requirement at the link level 
using QoS_BLOB infomnation or at the IP level via an extended dynamfe flow mapping 
mechanism. This invention report also proposes how to use these OoS information at RN and 
PDSN to provide Qos support to the R-P network and external network. 
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Figure 1 . OiffServ Domains in 3GPP2 Network System 
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Figure 2. Flow Mapping and DiffSen^ Conditioning for Downlinl^ Traffic: Solution 1 
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Figure 3. Flow Mapping and DiffServ CorKlitioning for Downlink Traffic: Solution 2 
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Figure 4. Flow Mapping and DiffServ Conditioning for Uplink Traffic: Solution 1 
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Figure 5. Flow Mapping and DiffServ Conditioning for Uplink Traffic: Solution 2 
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Figure 6. Flow Mapping and DiffServ Conditioning for Uplink Traffic: Solution 3 
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Figure 7. Integration of Solution2/uplink and Solution2/downllnk 
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